In an object-oriented computing environment, objects are modules of computer code that specify the data types of a data structure. That is, objects define a set of values and allowable operations. Objects additionally specify the kinds of operations, or methods, permitted to be applied to the data structure. The data structures and methods common to all objects of a certain kind are defined by a class of the object.
Object classes referred to as enterprise beans regard reusable software components that were originally developed by International Business Machines Corporation (IBM). When written in Java programming language, such classes are referred to as Enterprise JavaBeans, or EJB's (“Enterprise JavaBeans” is a registered trademark of Sun Microsystems, Inc.).
An entity bean is a type of EJB commonly used to model actions within a business process. For example, an application developer might implement an entity bean to retrieve and perform computation on items included within a purchase order.
In this capacity, entity beans offer many advantages to a computer user. Entity beans are modules that have already been created to perform a function. Consequently, entity beans can be reused in larger applications by a process known as instantiation. Furthermore, an entity bean is a portable and platform-independent, distributed object. As such, the class and the instantiated bean objects can operate on virtually any computer. In addition, an entity bean supports introspection, so that the object-oriented computing environment may be queried about the entity bean, its properties, methods and events. Such determinations may take place while the Java program is executing, i.e., during runtime.
An entity bean has a persistent state, and includes access to a data structure or other memory. The persistence property of entity beans allows the current state of the bean to be preserved in the case of a power outage, server crash, network failure or other interruption. When an entity bean is re-instantiated, the states of previous instances are automatically restored.
While entity beans are useful for persistence considerations, they do not accommodate queries that relate to historical data, i.e., non-current, dated state data. That is, while an entity bean may contain the current state of the entity, it has no history states. Put another way, all of an EJB's history (in flight, transit) states are not tracked by the entity bean itself. For instance, an entity bean associated with CPU usage may include the current amount of CPU usage, e.g., 20%, but may not include any history of the CPU usage over the past hour or week. In another example, an EJB may include a current stock price, but will not have information regarding the average or highest price of the stock over the course of an hour.
Because such historical data can be of great value in certain circumstances, users have conventionally been relegated to creating history entity beans associated with the EJB of interest. Continuing with the above example, a user needing past stock information has to create a number of history entity beans to store historical data whenever an EJB is updated. More particularly, the user must repeatedly write the code for and populate several history entity beans within the application for a single EJB of interest. The history entity beans must then be stored in persistent memory and associated with unique keys. The user must then scan for the stored history entity beans for a time period coincident with a past hour, or other time window of interest. Once the user has retrieved all the history entity beans of interest, then the user must do manual calculations to determine any statistic, e.g., an average or projection, necessary to answer the query.
While such conventional practices provide the opportunity to arrive at the requested result, they are relatively time consuming, tedious and error prone. For instance, if the user is only interested in a statistical perspective of the history data, such as an average, a minimum, or a maximum, conventional approaches provide no automated capabilities to support the user's need. Any conventional solution places a burden on a user to manually accomplish any needed calculations.
Moreover, storing the data associated with the multiple history entity beans needed for a single entity bean can consume large amounts of memory. Conventional processes keep all the history associated with the EJB in persistence, even though only the history of the object of the EJB over the past minute may be of interest, for instance. Keeping the memory and CPU usage for an entire day, or even longer, incurs costly overhead. There is neither a way to evict the history entity beans from memory, nor to delete the history data from a backend store.
For at least these reasons, there is a need for an improved method and system for querying historical data pertaining to a bean.